This is a deadlock bug.
The following is an example of deadlock thread dump:
"Thread-1": waiting to lock monitor 0x0000000006edfb38 (object 0x00000007d5d61438, a java.util.Properties), which is held by "Thread-0"
"Thread-0": waiting to lock monitor 0x00000000004ffe50 (object 0x000000077c839d40, a java.lang.Class), which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at java.util.Hashtable.get(Hashtable.java:333)
- waiting to lock <0x00000007d5d61438> (a java.util.Properties)
at java.util.Properties.getProperty(Properties.java:932)
at java.lang.System.getProperty(System.java:653)
at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:67)
at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:32)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.Launcher.getBootstrapClassPath(Launcher.java:362)
- locked <0x000000077c839d40> (a java.lang.Class for sun.misc.Launcher)
at java.lang.ClassLoader.getBootstrapClassPath(ClassLoader.java:1173)
at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1149)
at java.lang.ClassLoader.getResource(ClassLoader.java:999)
at java.lang.ClassLoader.getResource(ClassLoader.java:997)
at Test6977738$2.run(Test6977738.java:49)
"Thread-0":
at sun.misc.Launcher.getBootstrapClassPath(Launcher.java:361)
- waiting to lock <0x000000077c839d40> (a java.lang.Class for sun.misc.launcher)
at java.lang.ClassLoader.getBootstrapClassPath(ClassLoader.java:1173)
at java.lang.ClassLoader.getBootstrapResources(ClassLoader.java:1160)
at java.lang.ClassLoader.getResources(ClassLoader.java:1038)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:323)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:415)
at sun.util.LocaleServiceProviderPool$1.run(LocaleServiceProviderPool.java:100)
at java.security.AccessController.doPrivileged(Native Method)
at sun.util.LocaleServiceProviderPool.(LocaleServiceProviderPool.java:98)
at sun.util.LocaleServiceProviderPool.getPool(LocaleServiceProviderPool.java:80)
at sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:86)
at sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility..java:81)
at java.util.TimeZone.getDisplayNames(TimeZone.java:394)
at java.util.TimeZone.getDisplayName(TimeZone.java:345)
at java.util.Date.toString(Date.java:1025)
at java.util.Properties.store0(Properties.java:807)
at java.util.Properties.store(Properties.java:796)
at Test6977738$1.run(Test6977738.java:29)
- locked <0x00000007d5d61438> (a java.util.Properties)
More details about this bug are at
JDK-6977738 JIRA page.
This bug is reproduced under JDK 1.6.0_33.
It started at JDK 1.6.0_10, and has been fixed since JDK 1.7.0.
Execute the following scripts to run the test to reproduce the bug (assume the location of the jdk6 test project is jdk_test_home).
Linux:
${jdk_test_home}/scripts/6977738.sh [--monitoroff] [--javaloc path]
Windows:
%jdk_test_home%\scripts\6977738.bat [--monitoroff] [--javaloc path]
Example:
Use monitor to report and terminate the program when deadlock happens:
${jdk_test_home}/scripts/6977738.sh
Turn off monitor:
${jdk_test_home}/scripts/6977738.sh
--monitoroff
| Option | Function |
| --monitoroff, -mo | Turn off to stop reporting bug messages and ending program
when the test runs into the expected concurrency bug which is
a deadlock. User has to terminate the program manually when this option is set. |
| --javaloc | The location of JDK that is eligible to reproduce the bug, if your java environment is not eligible.
In this case, it's JDK 1.6.0_21. It should be the absolute path to the JDK's java starter and ended with "/". For example: ~/jdk/home/jdk1.6.0_21/bin/ |